Subject: Flow Control SIGlet

From: "Shannon Nix" <[email-masked]>
Date: Wed, 5 Jan 94 10:33:29 EST

Greetings,

I must have missed the ENTERBUSY signal which caused everyone to stop 
sending on this forum.  Robin, I guess those things can get lost!

Anyway... EXITBUSY.

My apologies for allowing this to fall idle, but things have been rather 
hectic as I'm sure is the case for many of you.

ISSUES:

1)  Circuit Level Flow Control Mechanism.  Three popular candidates:

    a)  ENTERBUSY/EXITBUSY (XON/XOF)
    b)  FIXED PACING (window size negotiated at CAPEX)
    c)  ADAPTIVE PACING  (IBM we still need an answer on patents!)

    Open to proposals under the following rules:

    a)  Proposal must accomodate 6611-like implementations which simply
        don't send FC of any kind and only respond to ENTERBUSY/EXITBUSY

    b)  Any adaptive pacing proposal must not be proprietary and must be
        included as a negotiable option only.

    NOTE:  We have a very viable ADAPTIVE PACING mechanism described by 
           Peter Gayek of IBM.  Assuming that this rather broad concept is
           not covered under patent, then I propose that the work to be done
           here is describe how implementations negotiate in such a way to
           accomodate existing 6611s (and other who wish to support XON/XOFF
           only).  

           FIXED PACING is simply a special case of adaptive pacing in which
           the receiver maintains a constant window size and the sender
           sends the lesser of that fixed window size and his peer's
           last allowed window size.

    SUMMARY:  If we allow negotiation of initial pacing window size in
              CAPEX and:

                 a) zero means I don't support pacing (XON/XOFF only)
                 b) I don't support CAPEX implies zero

              then, those that wish to only support fixed pacing may
              negotiate their initial window size and leave it at that.
              Its even conceivable that hybrid connections could be
              negotiated such that pacing in one direction is fixed and
              pacing in the other direction is adaptive.

   RELATED ISSUES:
         a) Can IPMs be piggybacked on data?  This is tied to our decision
            below about the shape of the transport mechanism.

2) Transport Mechanism.  We must support this (6611):

       |--------------->|
   DLSw|  simplex TCP   |DLSw
       |<---------------|

   We might choose to allow these to be negotiated in the first release:

       |  duplex TCP    |
   DLSw|<-------------->|DLSw
       | data & control |

       |     data       |
       |<-------------->|
   DLSw|  duplex TCP    |DLSw
       |<-------------->|
       |     control    |

   If we're to undertake the latter two, then someone needs to sponsor a
   concrete proposal describing a justification and an algorithm to 
   unambiguously negotiate the mechanism.

   RELATED ISSUE:
      a)  Do we need a transport level flow control mechanism (slam it 
          shut)?  If so, we need to describe 6611 compatability here as 
          well.

Rgds, Shannon
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)